Humm, this is going to be my first post, and I am trying to figure out where to start. Mostly because I want to just do something quick, and go live!!! I am excited! This is long overdue!
So, here we go. At the beginning of the week, I sent out a question on Twitter: What are the differences between Fast Reroute and Link Protection?
I came up with that question because I am currently working in a project involving MPLS and NorthStar, and yes, we are testing link protection. That made me remember that one of the discussion topics every time I taught MPLS and LSPs protection was that: “But Yasmin, what is the difference between the two options?” They can be confusing, they are similar but different in many ways, AND vendors use different terminology.
JUNIPER for example, calls the facility backup method described in RFC4090 Link/Node Protection, and the one-to-one backup method: Fast Reroute. CISCO on the other hand, calls the facility backup method Fast Reroute Link/Node Protection.
In this table I summarize the differences between the two options.
| RSVP LINK PROTECTION | FAST REROUTE | |
| Where is it configured? | Configured on ingress router under the LSP, and on the transit routers under protocols RSVP interface: set protocols mpls label-switched-path example link-protection (ingress) set protocols rsvp interface link-protection (ingress and transit routers) | Configured on ingress router only, under the LSP: set protocols mpls label-switched-path fast-reroute (ingress) |
| How many LSPs are protected? | – Many LSPS can be protected by a single bypass. – Any LSP requesting Link Protection and going across an interface that has been configured to provide link protection will be protected by the bypass created for that interface. | Only the LSP that is configured with fast reroute is protected by the detoured LSPs created. |
| Bypass or detoured? | Bypass (backup) LSP | Detour LSPs. |
| How many detour/bypass LSPs are created? | One for every protected link configured along the path, on both ingress and transit routers. | One from the ingress router and one from each transit router along the path |
| Does detour/bypass LSPs come up immediately? | yes, but only when at least one LSP requesting link protection is set up going through the interface | yes, it comes up at the same time the LSP that is requesting fast reroute comes up. |
| Who reroutes traffic when a failure occurs? | – Transit device or ingress depending on where the failure is. – Point of Local Repair (PLR) is router that detects the failure. Merge – Merge Point Router (MP) is router on the other end of the failed link. | – Transit device or ingress depending on where the failure is. -PLR is the router that detects the failure. -MP can be any node downstream from the protected facility |
| Ingress and egress of the bypass/detoured? | – The ingress of the bypass LSP is the router where a link is configured to provide link protection. Could be the ingress of the main LSP or any transit router along the path of the main LSP. – The egress of the bypass LSP is the router at the other end of the link that is configured to provide link protection. – If an LSP is going across R1=>R2 (in that direction), and the link between R1 and R2 is configured for link protection, the bypass LSP’s ingress is R1, and the egress is R2. | – The ingress of the detour LSPs is either the ingress of the main LSP or the transit routers along the path of the main LSP. – The egress of the detour LSP is the egress router of the mail LSP. The detours are constructed from each point of failure all the way to the egress of the main LSP. |
| Can they provide load balancing? | YES | YES |
| Standard | Facility Backup method defined by RFC 4090 | one-to-one backup method defined in RFC 4090 |
| Honored constrains by bypass/detour LSPs? | No constraints honored by default, but constraints can be added to influence CSPF routing of bypass LSP. | Administrative groups constraints only Detours do not honor bandwidth, path constraints, and so on |
| Advantage | Fewer states to maintain and refresh. | No configuration required on transit routers. |
Another frequently asked question regarding Link Protection and Fast Reroute is why are they needed, or what is the benefit of having then enabled, when an LSP is already configured with a primary path and a secondary path, AND the standby option is set.
The answer is: to provide sub-second traffic failover during a link failure.
In the following example, an LSP was created between router RA, and RB. This LSP was configured with a primary path and a secondary path, which were set up using strict EROs, to make sure they follow different paths.
[edit protocols mpls] user@RA# show | display set relative | display inheritance set path PATH1 R4 strict set path PATH1 R5 strict set path PATH1 R6 strict set path PATH2 R1 strict set path PATH2 R2 strict set path PATH2 R3 strict [edit protocols mpls label-switched-path LSP_RA=>RB] user@RA# show | display set relative | display inheritance set link-protection set adaptive set primary PATH1 set secondary PATH2 set standby
Notice that the primary path is now the ACTIVE path, and traffic is currently being sent on that path. Junos automatically makes the primary path the ACTIVE path, and keeps it as the ACTIVE, for as long as the path is operational.
Without link protection, when a failure occurs along the primary path, a notification has to be sent to the ingress to inform of the failure. In our example, imagine that there is a failure between R5, and R6. Traffic already in transit from RA to RB will be discarded, while the PATH ERR message travels all the way, from the point of failure (R5), to the ingress node (RA).
Once this PATH ERROR message reaches the ingress, traffic is switched over the secondary path. In other words, the secondary becomes the new ACTIVE path.
Again, the problem is that after the failure, traffic is going to dropped at the point of failure, until the ingress learns about the failure and switches over the secondary.
With link protection enabled for example, a bypass LSP is built to protect links configured to provide protection for LSPs going across that interface. Back to our example, the link between R5 and R6 is configured with link protection as shown below.
A bypass LSP is created to bypass the protected link. This bypass LSP begins at R5 and terminates at R6, with R7 being the transit router.
When a failure occurs, traffic gets re-routed along the bypass, while the PATH ERR is sent to the ingress node and the ingress node switches the traffic over to the secondary.
In our scenario, when the link between R5 and R6 fails, traffic is switched to the bypass. A PATH ERR message is sent to the ingress (RA), and the ingress activates the secondary path and moves the traffic to this path. The result is almost zero packet loss during the transition.
Recent Comments